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Controlling quality of service in a mobile communications system 

Background of the invention 

The invention relates to controlling Quality of Service (QoS) in 
mobile communications systems having a packet data transmission capability. 

A mobile communications system refers generally to any 
telecommunications system which enables a wireless communication when 
users are moving within the service area of the system. A typical mobile 
communications system is a Public Land Mobile Network (PLMN). A mobile 
communications network is usually an access network providing a user with a 
wireless access to external networks, hosts, or services offered by specific 
service providers. 

General packet radio service GPRS is a new service in the GSM 
system (Global system for mobile communications), and is one of the objects 
of the standardisation work of the GSM phase 2+ at the ETSI (European 
Telecommunications Standards Institute). The GPRS operational environment 
comprises one or more subnetwork service areas, which are interconnected by 
a GPRS backbone network. A subnetwork comprises a number of packet data 
service nodes, referred to as serving GPRS support nodes SGSN, each of 
which is connected to the GSM mobile communications network (typically to 
base station systems BSS) in such a way that it can provide a packet service 
for mobile data terminals via several base stations, i.e. cells. The intermediate 
mobile communications network provides packet-switched data transmission 
between a support node and mobile data terminals. Different subnetworks are 
in turn connected to an external data network, e.g. to a public switched data 
network PSPDN, via GPRS gateway support nodes GGSN. The term GSN 
refers commonly to both SGSN and GGSN. The GPRS service thus allows 
providing packet data transmission between mobile data terminals and 
external data networks when the GSM network functions as an access 
network. 

In order to access the GPRS services, a mobile station (MS) shall 
first make its presence known to the network by performing a GPRS attach. 
This operation establishes a logical link between the MS and the SGSN, and 
makes the MS available for Short Message Service (SMS) over GPRS, paging 
via the SGSN, and notification of incoming GPRS data. More particularly, 
when the MS attaches to the GPRS network, i.e. in a GPRS attach procedure, 
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the SGSN creates a mobility management context (MM context) The 
authentication of the user is also carried out by the SGSN in the GPRS attach 
procedure. In order to send and receive GPRS data, the MS shall activate the 
packet data address that it wants to use, by requesting a PDP (Packet Data 
> Protocol) activation procedure. This operation makes the MS known in the 
corresponding GGSN, and interworking with external data networks can 
commence. More particu.arly. a PDP context is created in the MS and the 
GGSN and the SGSN. The PDP context defines different data transmission 
parameters, such as the PDP type (e.g. X.25 or .P), PDP address (e g an 
' X.121 address), quality of service QoS and NSAPI (Network Service Access 
Point Identifier). The MS activates the PDP context with a specific message 
Activate PDP Context Request, in which it gives information on the Temporary 
Logical Link Identity (TLLI), PDP type, PDP address, required QoS and 
NSAPI, and optionally the access point name APN. 

♦k ™, R9Ure 1 '" UStrateS 3 GPRS P3Cket radio network implemented in 
the GSM system. For a more detailed description of the GPRS reference is 
made to ETSI GSM 03.60, version 6.1.0, and the cross-references thereof 

The basic structure of the GSM system comprises two subsystems- 
a base station system BSS and a network subsystem NSS The BSS and 
mob.le stations MS communicate with each other over radio links. In the base 
station system BSS, each cell is served by a base station BTS. A number of 
base stations are connected to a base station controller BSC which controls 
the radio frequencies and channels used by the BTS. Base station controllers 
BSC are connected to a mobile services switching centre MSC As regards a 
more detailed description of the GSM system, reference is made to the 
ETSI/GSM recommendations and The GSM System for Mobile 
Communications, M. Mouly and M. Pautet, Palaiseau, France, 1992 ISBN 2 - 
957190-07-7. ' OD,N * 

In figure 1, the GPRS system connected to the GSM network 
compnses one GPRS network, which in turn comprises one serving GPRS 
support node (SGSN) and several GPRS gateway support nodes (GGSN) 
The different support nodes SGSN and GGSN are interconnected by an intra- 
operator backbone network. In the GPRS network there may be any number 
of serving support nodes and gateway support nodes. 



BNSDOCID: <WO_0010357A1 J_» 



PCT/FI99/00661 

WO 00/10357 

3 

nn GPRS support node SGSN is a node which serves the 
The serving GPRS suppo ^ ^ ^ area of 

one or more cells in a ^^^^ , certain loca , element of the GSM 
SGSN is connected (v.a a Gb interface statjon system 

sys tem. This connection is Jj^^ sta , on BTS . The mobile 
BSS, i.e. to base station controllers BSC o comm unication 
station MS located in a cel. <^ mun ^" wit h the SGSN to the 

network with a BTS over a rad.o .nterfac a commun ication 

servlC e area of which ^^ ^^^ ~" *~ 

, network between the SGSN and the m J jdes packet - 

two . to achieve this, ^J^^^ MS and the SGSN. It has 
. switched transmiss.on of data packets be a physjca , 

t0 be noted that the mobile commun ,ca,on netw * orw P ^ ^ 
connection between the MS and The S GSN is also 

l5 structure are not significant with respec t to^ ^ vlr rf 

provided with a signalling ,nterface ^ the mobile services switching 

the mobile communication network and/ . ^ 

GPRS network to M ^rne/or an X.25 network, and 

data networks 11. such as an IP netwo <_ ^ inteK)perator 

se^ce centres. A border gat ^ ~ ^£ so conne cted directly to a 
25 GP RS backbone network 12. The GG » nvw^ GpRS subscribers . 

private corporate network or a host. addres ses. Routing 

POP addresses and routing infom *°" data unjts PDU from data network 
information is used for ,unne.«ng pro oco, «. unj: ^ ^ ^ The 

11 ,0 me , CUr t h :t"nd GGSr^ can be connected to the same physicai 
30 functionalities of the SGSN ana 

node. . HLR of the GSM network contains 

The home location register HLR sub scriber's 

GPRS subscriber data and ^^^£ZL The HLR also 
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w SN ,T !. Gr imerfaCe ,0 ,hS HLR <a direct si S" allin 9 connection or via an 
interna, backbone network 13). The HLR of a roaming MS and its seeing 
SGSN may be in different mobile communication networks 

An intra-operator backbone network 13, which interconnects „ 
a operates SGSN and GGSN equipment can be impiemented bTZns o, a 
local network, for example, such as an IP network. „ should be noted "hat an 
operator GPRS network can also be implemented without the 
backbone network, e.g. by providing all features in one computer 

,o bet w„ rf « in ' er -° perator backb °" e network enables communication 
10 between different operators' GPRS networks. 

In order to send and receive GPRS data, the MS shall activate the 
packet data address that i, wants to use, by requesting a POP activate' 
procedure. This operation makes the MS known in the corresponding GGSN 
and interworkmg with external data networks can commence More 
1= particularly, a POP context is created in the MS and the GGSN and the SGSN 
nf th ™ 3 C ° nSeqUence ' ,hree differe nt MM states of the MS are typical 
of he mobility management (MM) of a GPRS subscriber: idle state, standby 
state and ready state. Each state represents a specific functionality and 
information level, which has been allocated to the MS and SGSN. Information 

,h?:TT h '° ,h6Se S,a,6S ' Ca " ed MM ° 0nte,rtS ' ~ >" "» SGSN and 

the The context of the SGSN contains subscriber data, such as the 
subscriber's IMSI. TLLI, location and routing information, etc 

In the idle state the MS cannot be reached from the GPRS network 

« M» "° TT° informa " 0n ° n ° Urrent St3te ° r location of ,he MS. i.e. the 
25 MM context, is maintained in the network. In the standby and ready states the 

contltT '° GPRS ™' ' n ,hS GPRS — ' a « MM 
contex has been created for the MS, and a logical link LLC (Logical Link 

Control, ,s estab.ish.ed between the MS and the SGSN in a protocol layer The 

ready state is the actual data transmission state, in which the MS can transmit 

30 and receive user data. 

In the standby and ready states, the MS may also have one or more 
PDP contexts (Packet Data Protocol), which are stored in the serving SGSN in 
connection with the MM context. The PDP context defines different data 
transm.ss.on parameters, such as PDP type (e.g. X.25 or IP), PDP address 

35 (e.g. an X.121 address), QoS and NSAP,. The MS activates the PDU JZt 
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C9np Activate PDP Context Request, in which it gives 
with a specific message, Activate hu NSAp| 

+^ ti i I PDP tvoe, PDP address, i^uncu 
informat.on on the TLLI, PDh • iyp , mS rQams tQ ^ area of 

rjsrr.ES£»« - - — - - - 

SGSN. 

in Fin 2 a GPRS system comprises layered protocol 

TU pddc Tunneilnq Protocol i<jir; wimci 

The GPR Tunnel 9 ^ backbone ne(work . A1 , 

5 signalling between GPRS support n mechanisms 
PDP-PDUs shali be encapsulated by *»Gn>.T* G ^P ^ 
for flow control between GSNs ,f ^ PDU s in the GPRS 

The Transmission Control Protoco TCP, , «m- ^ ^ 
ba eRbone networMor protoc £ need a ^ ^ ^ ^ ^ ^ data 

LLptea — UOP is 

against corrupted GTP-puus. . backbone network 

detlnedinRFC^.Thelnte™ ^^^ignalling. The GPRS 
25 protocol used for routin user date 4 . ^ 

30 characteristics l a -,e 

GSM 04.65. The Logical Unk Control (LLU) p radi0 Wertace 

iogical link. The LLC sha.l ^'"^^^ GPRS radio sotutions wfth 

pro ,oco,s in order to ^^[^Z in OS M 04.64. The relay 
minimum changes to the NSS. The LL v , n the BSS . , n 

35 function relays LLC-PDUs between the Urn and Gb 
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the SGSN, the relay function relays PDP-PDUs between the Gb and Gn 
interfaces. The Base Station System GPRS Protocol (BSSGP) conveys 
routing and QoS-related information between BSS and SGSN The BSSGP is 
specified in GSM 08.18. The Frame Relay layer transports BSSGP PDUs 
> RLC/MAC layer contains two functions: The Radio Link Control function 
provides a radio-solution-dependent reliable link. The Medium Access Control 
funct,on controls the access signalling (request and grant) procedures for the 
rad,o channel, and the mapping of LLC frames onto the GSM physical 
channel. RLC/MAC is described in GSM 03.64. 

Fig. 1 also shows the structure of a data packet DP. It comprises a 
payload PL carrying actual user information, and a number of headers H for 
identification, routing and priority information, etc. Each protocol layer adds a 
header of its own to the data packet. The item PrT will be explained later. 

Various identities are employed in the GPRS. A unique International 
Mobile Subscriber Identity (IMSI) shall be allocated to each mobile subscriber 
in GSM. This is also the case for GPRS-only mobile subscribers A GPRS 
subscnber, identified by an IMSI, shall have one or more temporarily and/or 
permanently associated network layer addresses, i.e. PDP addresses which 
conform to the standard addressing scheme of the respective network layer 
serv.ce used. A PDP address may be an IP address or an X.121 address 
PDP addresses are activated and deactivated through SM (session 
management) procedures. 

The NSAPI and TLLI are used for network layer routing A 
NSAPI/TLLI pair is unambiguous within a given routing area. In the MS the 
NSAPI identifies the PDP service access point (PDP-SAP). In the SGSN and 
the GGSN, the NSAPI identifies the PDP context associated with a PDP 
address. Between the MS and the SGSN, the TLLI unambiguously identifies 
the logical link. NSAPI is a part of the tunnel identifier (TID). TID is used by the 
GPRS tunnelling protocol between GSNs to identify a PDP context A TID 
consists of an IMSI and an NSAPI. The combination of IMSI and NSAPI 
uniquely identifies a single PDP context. The TID is forwarded to the GGSN 
upon PDP Context activation and it is used in subsequent tunnelling of user 
data between the GGSN and the SGSN to identify the MS's PDP contexts in 
the SGSN and GGSN. The TID is also used to forward N-POUs (network-level 



BNSDOCID: <WO 0010357A1J_> 



10 



PCT/F199/00661 

WO 00/10357 

7 

Packet Data Units) from the old SGSN to the new SGSN a, and after an inter- 
SGSN routing update^ ^ of ^ 1Pv4 or 

Each SGSN and GGSN ^ for ^ 

IPv6, for inter-communication over the w _ 

GGS N, this IP address corresponds ^^^Z^ eJrt erna, 
The GPRS *anspare*ly transports POP P $ ^ ^ 

networks and MSs. Between the SGSN and tn GTP 

and transferred with the '^^ ^ d ^ d ^a tunne, iden«er <T,D) 

and a GSN address. Ali POP ^PDUs ^ ^ ^ ^ ^ ^ ^ 

GPRS routing purposes. Encapsuiat PDP .p D Us to be delivered to 

SGSN, and at the GGSN. *****£"J£Z%. Ms , the SGSN, or the 
and associated with the correct PDP context in GpRs 
GGSN. Two drfferent -caps^on s hem s are u e ^ 
; backbone network between two GSNs, and on 

between a SGSN and an MS. backbone network 

Be,Wee p n op an pDU "I 3 : GPR — Protocol header, and it 
encapsulates a PDP-PDU with a GP ^ |n an 

inserts this GTP^PDU . a TCP-PDU or ^ ^ and 

■0 IP-PDU. The IP and GTP-PDU neaa , GSN PD P context. 

tU nne, endpoin, iden«ers necessary ,.o ™«£ ^ „ uniquely 

Between an SGSN PD Mg ^ 

-«^^- 1U ^^^" w l a *. MS in.ia.es the POP 
the Attach function. NSAPIs are assia 

25 Context Activation function. data units (PDUs) 
Quality of serv,ce (QoS) defines n ^ 
' are handled during transmission trough the GPRS netwo 

QoS defined for the PDP addresses con M IN o ^ ^ 

buffering (the POU queues) and ***** ^ ^^erent QoS levels will 
3„ GGSN, especially in a congeste s,.ua*oa ^ ^ 
present .different end-to-end delays, bit rates and 
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high level of throughput, interactive applications being one example. These 
different requirements are reflected in the QoS. If a QoS requirement is 
beyond the capabilities of a PLMN, the PLMN negotiates the QoS as close as 
possible to the requested QoS. The MS either accepts the negotiated QoS or 
deactivates the PDP context. 

Currently, a GPRS QoS profile contains five parameters: service 
precedence, delay class, reliability, and mean and peak bit rates. Service 
precedence defines some kind of priority for the packets belonging to a certain 
PDP context (i.e. which packets will be dropped in case of congestion). Delay 
class defines mean and maximum delays for the transfer of each data packet 
belonging to that context. Reliability in turn specifies whether acknowledged or 
unacknowledged services will be used at LLC (Logical Link Control) and RLC 
(Radio Link Control) layers. In addition, it specifies whether protected mode 
should be used in case of unacknowledged service, and whether the GPRS 
backbone should use TCP or UDP to transfer data packets belonging to the 
PDP context. Furthermore, these varying QoS parameters are mapped to four 
SAPIs (Service Access Point Identifiers) available at the LLC layer. 

The GPRS network is not capable of meeting the various QoS 
requirements of Internet applications. IP (Internet Protocol) traffic takes place 
20 between a mobile host and a fixed host located in an external network, e.g. in 
the Internet. Different Internet applications require different kinds of service, 
i.e. QoS, from the underlying network. Thus, when the mobile host is using 
GPRS to access the Internet, the GPRS network should be capable of 
meeting various QoS requirements of Internet applications. There are actually 
25 at least two IP traffic types that should be taken into account: real-time and 
non-real-time traffic. One example of real-time traffic is voice transmission. E- 
mail and file transfer in turn are examples of non-real-time applications. ' 

Currently, QoS parameters can only be associated with a certain 
PDP context (i.e. a certain IP address, if the PDP type is IP). Therefore, 
30 setting different QoS values for different applications that use the same IP 
address is not possible. This is a very severe drawback of the current QoS 
scheme. The current GPRS specifications also define only very static QoS 
behaviour: A mobile station can only initiate a QoS negotiation when activating 
the PDP context. To summarise the main problems: The GPRS QoS scheme 
35 is too static, i.e. the QoS cannot be changed by the MS or the GGSN after the 
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Q0S has been * the « ^-^^^2 

use the same IP address must also he same p^ Qf 
values. This is obviously no. ?££££ P mxjt ?„ voice transmission, 
various Interne, •W*^'^^ W J W . f,le transfer, and high 
real-time video, compressed video, e m 

^^?<-Z££rZ£tt^ and Best- 
three traffic types: Guaranteed I Se^ice (o wjthQUt 

Effort Service. Guaranteed Service ^ ^ for , his 

introducing a large amount o overhead to * V ^ ^ different 

overhead is that end-to-end traffic flows should ^ 
application connections. Therefore, trosq ^ ^ sys(em 

management, controi information exchange^ and tn^ P 
, Controlled Load provides unloaded network beha ^ 

situations, Controiled Load can e -piemente J M probably be easier 
Therefore, implementing C(**ll» guarantees on transmission 

, nan Guaranteed Service, which n e ed s s, 9 ^ ^ ^ qqS ^ 

delays etc. Best-Effort Service does no, need any 
.0 is thus very easy to implement in ^"T^ are based on the idea that no 
Drfferentiated Sendees ,n the Interne : . informa tion 
, ata flows are needed, but insteac every d*a a c e,^ ^ ^ ^ ^ ^ 

" =r ^ eTm^r ^ ,om the capacity and system 

- nio, ^rar;^— ^ - - in - mobi,e 

communications network. 

™rrrrr-s^ -» »»» — • — 

data transmission capability. 
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Another object of the present invention is a new QoS scheme which 
provide, support for .nternet app.ications and their QoS requirement 
mob.le communications systems having a pack et data transmission cap" 
The objects of the invention will be attained by the method and 
5 equipment wh.ch are characterized by what is disclosed in the attached 

th eT h e l C,aimS - Preferred emb ° dimentS <*«"• invention are disclosed 
the attached dependent claims. 

POP con^T? '° ^ inVenti ° n ' in C ° nneC,i0n With (i e ' duri "9 or after, 
POP context activator,, a mobile station MS may activate more than one QoS 

> profile w,th,n the POP context. ,n other words, an active POP context fo^an 

MS comprises severe, QoS profiles. Transmitted packets are equipped wi h a 

profile ag or profile indicator indicating which profile the packet relates to Thi 

pe^ntT Preferab ' y 2 ' 3 " 4 ' en9,h ' i e ' 4 ' 8 ° r 16 

When the MS begins to execute a new application requiring 
different sen,,ce which cannot be provided by the existing profiles (i.e one 
which has not been used during this session) a corresponding profile must be 

I: 2 ' n H323 SGSN ' eXamP ' e ' ^ MS C0U ' d that^ FTP re ulr 

profile 2. H323 requires profile 3. etc. Alternatively, this information can be 

configured manually or by some external signalling methods, e.g. QoS profile 

establishment procedure or RSVP (Resource Reservation Protocol) signalling 

According to a simple embodiment of the invention, the prior art 

s,nge profile for the POP context is replaced with muttiple profiles, one to 

each application, application type, or data flow, or aggregate for several flows 

oroffleH ' ,IPte rf Pr ° ffleS are referred *> as «°»-'*ed P-files, or simply flow 
profiles. According to a preferred embodiment, there is provided a hybrid 
between the prior art single profile and the concept of separate flow profiles 
provided by the simple embodiment (i.e. one proflle for each application type 
or flowx Th,s hybrid consists of one M S-re,a.ed proflle and several application 
related flow profiles. The hybrid-profile concept is based on the idea tha, some 
P aram *ters characterise the MS's maximum capabilities (such as a 
maximum bit rate on the R reference point between an MT and a TE) or its 
user's maximum rights (such as a maximum allowed rate or user importance 
first class, business, etc., Such maximum capabilities or rights are preferably 
defined ,n a common MS-related profile. If one of the flow profiles lacks a 
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P aramete, then the corresponding 

mean bit rate, precedence and d ^ ffj be different for each flow), 
characteristics of a particular flow, hence * may _ 

, nstead of "^^fion Protocol, RSVP. or ,P 
mapping to an external QoS (Re- ^ when 

, differentiated serv.ces). For •« m P»' fl|e 4) for RS VP whereby 

RSVP request, could add a QoS P** indicating profile 4 a nd 
an RSVP packets will be encapsu ated ,n G P SAp , . Appropria te' 

they wil, be carried on the LLC layer ^ h ^ ^ ^ SAPl 

m eans that there is a certa.r J ^ ^ ^ SAp , (fou , 
l5 . value, in other words, a QoS P*« throughpu t can be defined on a 
level QoS value. This implies that he peak ^ 9 > ^ ^ ^ 

per - M S basis (instead of on a profile t s,s)^ea 9 rf ^ Then 
Lined for both the US in question and each <l° ^ ^ ^ 

neither the traffic per flow nor » « « ffles ^ b e 

responding "T^^JHS.. P—*" ne3 ° teti0n ' * 

mternet applications are typically ^Z- 
do wn,ink fiows have different QoS \ s typically a 

demand applications, video games e , nave any strict 

signalling link which requires -liable transm,ss on but ^ ^ 

de ,ay requirements. The correspond, g dow*K a« ^ ^ ^ 

information having just the °PP os ' ,e : eq ~ undue ham . Two parameter 
delay but missed frames can be rgnored for upllnk and 
sets have to be negotiated (erther as ^ for upljnh and 

downlink, or a QoS profile includes two separ 

— ""The invention enables virtually any ^J^J^Z 
US ed— oust, e.g. a dedicated QoS P^< ^ , he same 1P 
use r applications being executed in the moo 
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address. (An n-bit profile tag can distinguish between 2" different profiles) 
Therefore, the present invention provides support for various Interne 
appLcafons and their QoS requirements using on.y one IP address, which is 
not poss.ble using the current QoS scheme of the GPRS. Moreover if a QoS 
5 profile has to be renegotiated, the same profile tag can stiff be us d Th" 
overcomes the problems re.ating to the static prior art QoS schemes Further 
the present invention introduces little overhead into the mobile 
communications system as a whole. 

Implementing the invention involves some new issues. One of them 
) , how the edges of the network can map the packets from the correct flow or 
profile Accords to one possible solution, a process in the TE/MT/MS and 
GGSN (or some other node) manages the flow/profile associations and keeps 
track of which flows relate to which applications (or higher-level QoS 
schemes/aggregated flow, such as RSVP). This process can indicate these 

wNch' t TE/MT/MS bV Pr ° Viding 6aCh P3Cket With a «™<e tag 
wh.ch the MS uses to perform policing and scheduling and to forward the 

packet us,ng the proper means (LLC acknowledged or unacknowledged) In 
th,s context, proper means' implies e.g. an appropriate LLC link using a 
part.cu.ar SAPI/QoS value (mapping to underlying layers based on the 
negotiated QoS profile values and using the reserved capacity for the profile 
flow). Alternatively, the TE can use some other means and the MS can add 
the profile tag based on that information. The TE/MT/MS in turn forwards the 
profile tag in each packet it transmits. 

At the edges of the network (such as at the MS and the GGSN) a 
process may analyse every incoming packet and deduce to which flow/profile 
a given packet is associated and inserts the corresponding profile tag in the 

o7ds in ,P^ a r a,y f d6dUCti0n ^ baS6d ° n an ' P ^ ™« (ToS 

TCP/unP i C ' aSS " DS " ,PV6X S ° UrCe and destination ^dresses, 
TCP/UDP port numbers, or an RSVP flow (a flow is identified by its IP address 

and port number). Both edges must maintain a table .inking the profile tag to 

the corresponding applications (or higher-level QoS schemes). The edqe 

wh. ch establishes a new profile association must signal the association to the 

other edge. The mechanism for this kind of signalling can be GPRS-specific 

mechan.sms or some other suitable mechanism, such as RSVP carried across 
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GPRS and mapped ,o OPRW-* — « — 3 - Pr0f " e 
— " -T may use AT -^^SE 

r ^rj'^ss^ — es data packete 

related to certain applications/port numbers^ RFC -1883 as a 

The GTP uses flow labe, wMch „ requests 
mechanism to enable a source to label those P Qr rea ,. tjme 

special handling by the IPv6 .outer, such s nor,^ ^ ^ q ^ ^ 
service. In a network using GTP. the . ^ assodated with . 

P^W^^^^^^S^ are used .or each POP 
,t is also conceivable tha mu topi ^ ^ ^ 

context and the packets ^ jn GPRS the precedence could be 

associated QoS parameters. For example, ^ , ( 

indicated per packet, whereby it ,s not part o th g 

tha , value o. the flow. H^^^^* be set by the edge of 
20 default value for the precedence Su^am ^ ^ ^ , p 

the network in order to map the external u P additional 
priority), or because more traffic «"an "egofated discard wt , 

packets might be marked. Such markrng m. . » S cp gnd * TP neadere . 
Lively, a suable ,ag ^egot^on. The Oo3 

The invention facilitates oyn ^ wi , nou t 

parameters associated wrth each flow can be < ^ q( ^ 

affecting other flows. Such need arise, the 

network, or by an intermediate node . MMo al^ sh ^ g ^ 

edges can also renegotiate a new mapping to extern 

30 number. Q s pr0I j| e can involve all 

Negotiaflng and renegotiating a QoSp QoS class 

parameters included in the p«*. ^ of *e par QoS aass value could 
(e .g. a bit vector or an tnteger valued T P , p other words , 

indicate, and also define, values for independe P independ ent 
3 5 well-defined relations exist between the class 
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parameters. The classes could be defined in some ranking order A B etc so 
that the negotiation can be performed in one step as with LLC and SNDCP 
parameters. This requires that if a network element supports class A it must 
also support all classes below it, i.e. B, C, etc. The QoS profile in the 
negot.ation should be replaced by a QoS class field which is only 4 to 8 bits 
(16 to 256 different classes). This could be simplified by requiring that peak 
and mean bit rates are always MS-specific (not flow-specific) If such a 
requirement is considered too restricting, an additional field or two fields could 
be used for bitmaps indicating that a given class number in the (re)negotiation 
has a peak/mean bit rate combined with an MS-specific value. Yet another 
alternative is to separate the peak/mean bit rate from the classes and define 
them as an MS-specific parameter which is negotiated separately from the 
classes. 

At both edges of the network, when a new external QoS reservation 
request (e.g. an RSVP PATH message) arrives, a process decides whether a 
new flow should be established or an existing flow reused (modified if 
necessary) in order to limit the number of simultaneous flows. One flow should 
be the default flow to which packets are associated if they do not include flow 
identifiers. 

Policing of packets can be performed on the LLC or SNDPC layers 
It could be performed on a per-MS basis or on a per-class or per-context 
basis. Policing should be performed for N-PDUs because charging counts N- 
PDUs. Scheduling of packets can be performed on the BSSGP layer because 
it sees cell-specific pipes and retrieves traffic related to several MSs The 
scheduling algorithm should take into account the delay and precedence 
defined in the QoS profile in question (user priority). Admission control should 
consider the total load and calculate/decide what bit rates can be allocated to 
an individual MS. This can be summarised as follows: A process on the 
SNDPC layer polices the flow and forwards the packets which pass the policer 
across the LLC layer to the scheduler on the BSSGP layer. The scheduler 
sends the packets to the BSS, or discards them in an overload situation In 
connection with a flow/profile establishment, admission control calculates on 
the basis of the total load situation which bit rates can be guaranteed to a 
given flow. 
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According to a preferred embodiment of the invention the profile 

■ H ated bv the profile tag associated with each data packet includes at least 
indicated by tne prome y information has 

priority information and detay 'W*™*^™ ' and thus als0 

^o or mora values i— * ^ other words . it 

defines the order ,n case of network congestion. Tne 

defines a dropping preference to be used n ^ 

priority information may also ^^T^Z^ltle^ 1 below). 
At least two traffic types naving exa mDle for non-real- 

interactive traffic, attenaea indicated by using 

uncharacterised traffic, and best-effort , traffi c_The y Qn 
different delay class values for each type. The traffic typ ha P 
retransmission strategies and ^^J^^Z^.^ 

- Wording . 0 ^-^^rr^'r:!: s 

, addition to employing reliability at a PDP contort . associated 
the prior art, reliability is also directly associated with the prot 

!h Z data oacket The communications network, e.g. at the LLC ayer, is 
with the data packet.. u"= %Al hirh is associated with 

different "•"•**J*° < £ com munica.ions network, e.g. a, the 

5 any one or several legs in the mo ^ 

radi0 interface and/or ^—^^ having a higher re,iab ? 
One connection may be a conne anothe r connection may be 

due to a retransmission ^^^^Z^. — P«*-» 
a connectionless path (e.g. using UDP) having a 
30 are multiplexed over these connec .on based on the ^ J ^ 

information -^"^ the OoS profiie tag 

profile or indicated by the P acket >. a reljable con nection- 

r^irinh ^ ~ ^ re<,,re a • connection- 
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oriented and the connectionless paths can be established to transfer packets 
of only one PDP context or they can be used by several PDPcontexts 
Furthermore, the establishment of different paths with different reliability 
properties can be dynamic or static (i.e. on demand or when the tunnel (PDP 
context) is created). This concept of the invention may applied in any packet 
data communications network, even in one not using any PDP context such 
as TCP/IP, ATM, or X.25 networks. 

As noted above, the PDP context defines a kind of a transmission 
tunnel w.th specific characteristics through a mobile communications network 
As in conventional networks, the parameters of the PDP context may include a 
PDP type (e.g. X.25 or IP), a PDP address (e.g. IP address), and an NSAPI 
The PDP context may also optionally include one or more QoS parameters 
For example, a mean and a peak bit rate for the whole PDP context can be 
used. The QoS of the PDP context may also include reliability. If both the 
PDP-level QoS profile and an additional QoS profile are to be used, the traffic 
policing may partly be based on the QoS values related to the PDP context 
e.g. on the mean and peak bit rates. Therefore, if the user is sending at too 
h.gh a speed, the priority of his or her data packets of certain flows could be 
temporarily decreased by the system. This guarantees that packets not 
conforming to the PDP level QoS contract are discarded first if needed. In 
addition, QoS information in the additional QoS profiles within the PDP context 
could be relevant only within the PDP context in question. This being the case 
the QoS profile of a certain flow is taken into account only in relation with the 
global default QoS Profile of the PDP context. 

A further feature of the present invention may be a mapping of the 
QoS parameters used in the mobile-communication network to those used in a 
user application in said mobile packet data terminal or those used in an 
external communication system, and vice versa. The mapping is performed for 
each packet entering or leaving the mobile communications system. 

The profile tag in the data packets may be located in a packet 
header, in a lower layer protocol header, or as part of the data itself. The QoS 
controlling may also be based on the QoS information in the QoS profile which 
is related to a certain PDP context, the priority and traffic type information 
included in the data packets, or both. 
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u A-r^m of the invention involves also charging of the 
oollec , intonation on the ^^^ X^ M 

- pdp - , : — r 

Accorainy network, such as the 

, m obi,e communicates ^GPRS) of GSM or its evolution in the UMTS 
Genera! Packet Rad.o * < ^ ptamBnWl in a propria way: 

networks, such as UMTS. 

Bri ef description o, the severa, views , drawing 

,n the following, the inventor, will be described n g 
means of preferred embodiments with reference to the acoompa y 

20 draWingS ' FirTIustra.es a GPRS network architecture; 

F,g 2 Iustra.es a GPRS transmission plane and the use o, the 

proflte - 9 --2r:i:?;r;d <* ^ ^ ^ * 

25 Sin9 ' e ^^TLrates interworking between different network elements; 
Fig 5 shows a context activation procedure; and 
Fig. 6 shows a context modification procedure. 

D eUi.ed d escrip«ono,meinven«on ^ ^ ^ ^ ^ 

30 As shown in F,g. 1 , the P^" 1 transmiS sion capability, 

mobile communications system having a packet 

» icnpi or 'PDP context' as used 
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and in at least one network element or functionality, which state provides a 
data packet transmission path or a tunnel with a specific set of parameters 
through the mobile communications network. The term 'node' as used herein 
should be understood to generally refer to any network element or functionality 
which handles the data packets transferred through the PDP channel. 

The invention can be especially preferably used for providing a 
general packet radio service GPRS in the pan-European digital mobile 
communication system GSM or in corresponding mobile communication 
systems, such as DCS 1800 (also known as GSM 1800) and PCS (Personal 
Communication System). In the following, the preferred embodiments of the 
invention will be described by means of a GPRS packet radio network formed 
by the GPRS service and the GSM system without limiting the invention to this 
particular packet radio system. 

A prior art data packet DP consists of a payload part PL and various 
headers H, one for each protocol layer. According to the invention, the mobile 
station MS and the support nodes SGSN, GGSN, etc. maintain multiple 
profiles Pr, each profile being tagged with a profile tag PrT. Each data packet 
DP also comprises a profile tag PrT indicating the relevant one of the multiple 
profiles Pr. Most protocols use headers where some bits are unused, 
redundant or reserved for further use. Such spare bits can be used for 
indicating the profile tag PrT, since typically only 2 to 4 bits are needed (4 to 
16 different profiles per MS). If the headers do not have such redundant bits, 
the headers can be extended, or the profile tag PrT can be appended to the 
payload part PL 

Fig. 3 illustrates the hybrid profile concept of the invention. For each 
PDP context, there is an MS-specific and/or a PDP context-specific default 
profile Pr 0 which provides default values for some or all of the QoS 
parameters. For each application, application type or flow associated with the 
MS, there may be a separate profile Pr. The separate profiles Pr are 
associated with the PDP context so that a profile tag with a small number of 
bits (e.g. 2 to 4 bits) is sufficient to indicate the relevant profile Pr. Fig. 3 shows 
one such profile, having an identifier of 2 and relating to an FTP application. 
For this application, there are separate values for service precedence (y1), 
delay class (y2), reliability (y3) and mean bit rate (y4). However, no values are 
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defined for the peak bit rate and hence the default value (x5) of the default 
profile Pr 0 will be used. 

The QoS information associated with the profile indicated by the 
PrT is employed in various nodes in the GPRS system for scheduling and 
5 policing the transmission of the data packets. As noted above, in the present 
GPRS specifications, QoS is associated with the PDP context, which causes 
the various problems described above. According to the present invention, 
each data packet DP comprises a profile tag PrT whereby the scheduling and 
policing can be performed on a packet by packet basis (depending on the 
10 flow). More particularly, the profile Pr associated with each data packet DP 
indicates at least one QoS parameter, and the scheduling and the policing of 
the transmission of the data packets is made on a packet by packet basis 
according to this QoS parameter indicated by the profile, while, however, 
within a "transmission tunnel" defined by the PDP context, if such a default is 
15 defined for the PDP context in question. 

According to a preferred embodiment of the invention, the QoS 
information associated with the profile indicated by the profile tag includes at 
least priority information and a delay class information, and optionally, 
reliability information. The delay class information has two or more values 
20 indicating the importance of the packet and thus it also defines the order in 
which data packets should be handled in case of network congestion. The 
priority information may also define a Nominal Bit Rate as in the SIMA 
approach, or indicate the discarding order of packets/flows. In addition to 
optionally having mean and peak bit rates in the profiles, this preferred 
25 embodiment of the invention requires typically the following modifications to 
GPRS specifications: 

1) As shown in Fig. 2, SNDCP and GTP headers should carry 
additional bits for transmitting a profile tag (GTP bits are needed on both 
directions, SNDCP bits could in certain cases be used only for uplink data). In 
30 addition, IPv4's Type-of-Service field or IPv6's priority field or Traffic Class field 
could be used in the GPRS backbone if IP routers etc. should also support 
prioritisation of packets and QoS-based queuing or scheduling. RSVP could 
also be used within the GPRS backbone for providing specific flows with 
independent QoS handling. IPv6 traffic flows may be established for 
35 transmitting data belonging to certain traffic types. It is also feasible that no 
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extra bits be allocated in the GTP headers, but the profile information is 
carried by lower layers. For example, if the underlying GPRS backbone 
network supports such mechanisms, this information can be included in an IP 
header or some other lower layer protocol header. This being the case, the 
SGSN and the GGSN should be capable of recovering this lower layer 
information in order to reuse it. The profile tag can be added to data packets at 
the Gb interface as well, e.g. to BSSGP protocol messages. Then the QoS 
information can be mapped to Frame Relay or ATM concepts at SGSN and 
BSS. 

2) In prior art system, a PDP context has a single QoS profile using 
a single SAPI. Several PDP contexts could use the same SAPI if their QoS 
profiles are similar. According to the invention, a single PDP context can use 
several SAPIs. The flows using the same SAPI should have similar QoS 
profiles. PDP contexts are multiplexed over several LLC SAPIs (e.g. if 
reliability is used as one of the QoS parameters). In other words, the SNDC 
layer should be capable of multiplexing NSAPI on several SAPIs according to 
the QoS profile information at the LLC layer, as will be described in more detail 
below. 

No modifications are necessarily needed in the lower radio interface 
protocols, like RLC. However, radio interface protocols could be replaced later 
with newer protocols, such as Wideband CDMA (WCDMA). The present 
invention is applicable also in such a case and similar QoS support 
(prioritisation, traffic type/delays) to the one described herein could inherently 
be implemented into those radio protocols. 

Fig. 4 illustrates interworking between different network elements. 
After these modifications, a parameter-level mapping between differentiated 
services in the Internet and in GPRS may be provided as follows, for example: 

Priority information in the Internet is mapped to service precedence 

in GPRS. 

An indication concerning real-time vs. non-real-time requirements in 
the Internet is mapped to delay class and/or reliability information in GPRS: at 
least two delay types are needed, but mapping of traffic types more precisely 
to several delay classes is also possible. 

Reliability information may be used to indicate the reliability 
requirements of each application in the form of one of at least two reliability 
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classes. If reliable transmission (retransmissions, checksums and/or TCP) is 
needed, the profile associated with the data packets indicates reliability class 
1. If reliable delivery over the radio interface is needed, but UDP in the GPRS 
backbone is sufficient, the profile associated with the data packets indicates 
reliability class 2. Depending on the requirements, the profile associated with 
the data packets may alternatively indicate reliability class 3, 4 or 5. Reliability 
classes 4 and 5 will be used for real-time traffic. 

A further feature of the present invention may be a mapping of the 
QoS parameters used in the mobile-communication network to those used in a 
o user application in the mobile packet data terminal or those used in the 
external communication system, and vice versa. The mapping is made for 
each packet entering or leaving the mobile communications system. In the 
following, two examples of the mapping will be given. 
Example 1 . 

5 Simple Integrated Media Access (SIMA) is a new simple approach 

presented as an Internet- Draft by K. Kilkki, Nokia Research Center, June 
1997. Internet-Drafts are working documents of the Internet Engineering Task 
Force (IETF), its areas, and working groups. SIMA is used as an example of 
an Internet QoS scheme because it is capable of providing a uniform service 

jo concept for different needs from file transfer applications using TCP/IP 
protocol without loose delay and packet loss requirements to realtime 
applications with very strict quality and availability requirements. According to 
the SIMA concept, each user shall define only two issues before the 
connection setup: a nominal bit rate (NBR) and the selection between real- 

25 time and non-real-time service classes. The NBR may have eight values 0 to 
7. Mapping of parameters from SIMA to GPRS and vice versa may be as 

follows, for example: 

Real-time/non-real-time bit: if this bit indicates real-time require- 
ments, it is mapped to GPRS delay class 1 , otherwise it is mapped to delay 

30 class 4. However, delay class 3 may be used for non-real-time services in 
case there is a special way to indicate best-effort traffic, e.g. this bit does not 
always have to be present, or a more precise definition is used to differentiate 
real-time, non-real-time, and best-effort traffic. A lower Reliability Class value 
may be assigned to real-time traffic than to non-real-time traffic in GPRS. 

35 Generally, Reliability classes 1, 2, and 3 are usually used for non-real-time 
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traffic and classes 3, 4, and 5 for real-time traffic in GPRS. For non-real-time 
traffic, the higher the NBR is, the lower is the Reliability Class value suitable 
for transmission. 



NBR values 


GPRS service precedence value 


6 and 7 


1 


3, 4, and 5 


2 


0, 1, and 2 


3 



It should be noted that the Service precedence and the Delay class 
parameters have here a somewhat different meaning from the current GPRS 
specifications, where those parameters are associated with PDP contexts, not 
with each application. Thus, different names, such as priority or Nominal Bit 
Rate and traffic type, may also be chosen for the parameters. The QoS Profile 
may include all the existing parameters (service precedence, reliability class, 
delay class, mean bit rate and peak bit rate). Alternatively, it could only include 
part of the parameters, such as only the mean and peak bit rate. The QoS 
Profile could also include a maximum burst size parameters to ease buffer 
allocation procedure. 

QoS scheduling in GPRS network elements (e.g. in an SGSN and a 
GGSN) is based on the delay class. This requires that at least two buffers 
exist (and at most as many as there are different delay classes): one for real- 
time packets (this buffer should be much smaller!) and another for non-real- 
time packets. Real-time traffic should always be sent before non-real-time 
traffic. Service precedence defines the order in which packets can be dropped 
in case of network congestion. 

Example 2. 

Mapping a Type of Service (ToS) octet in the headers of IP PDUs to 
GPRS attributes. The ToS octet in an IP header is not widely used at the 
moment. Its original purpose was to include traffic type information and to 
specify what kind of service is required from the packet delivery. Because the 
ToS octet is not in common use nowadays, it is possible to redefine the bits in 
that octet for the purposes of the present invention. A definition of the ToS 
octet is given in RFC 791. Bits 0 to 2 of ToS give the preference, bits 3 to 5 
give the ToS required by the packet (e.g. delay, throughput, and reliability 
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J ^ a to 7 are reserved for future use. RFC 1349 
,evels requested), and bits 6 to 7 ^ ^ ^ 

extends the ToS field by one bit (taken from 

Thus . 4 bits can be used to ind.cate a Tob. QpRS 
Mapping between the precedence bits (0 to 2 in 



| y.tx/alues (0 to 2) 
111 and 110 


^rvir^ precedence value 
001 (hiqrmst Dnontv) 


mi 1Q0. and 011 
010, 001- and 000 


010 (normal priority) 
t Q1 1 (lowest priority) I 



traffic type information (i.e. ToS field in tne 

class: _ _,_ _ _ . . used to indicate the delay 
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^ -r c f, 0 iH i<? used to indicate the delay 
„ on.y .he M 3 in the ToS **- used ^ 2 

requirements in ,P header, value , C or ^ 2 4 effort) . ■ 

3nd va,ue1 0 «thebi t 2 s™ppedJoGPRS ^ay ^ de|ay 

" * e I h t Jtt s 6) are available for tha, purpose, one possibie 
requirements, i.e. 4 bits (bits 3-6) are av tQ b|( 

Jpping could be: bi, value 100° is gapped ' ca ss 2 (i^to vaiue 001), ToS 
value 000), bit value 0100 to GPRS defcy class 2 ( 
values 0010 and 0001 to GPRS delay class 3 (.* to 
v . , tip tnvaue011 . 
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values 001 u ana uuu . ^ — - 

value 0000 to GPRS delay class 4 (i * to value ^ ^ 
Another way of mapping the IP s ToS mt ^ 

selecting the GPRS ^..^"T^^:--^ *• 
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selecting the GPRS delay Cass. . ' a(Jditiona , bite . 

,a,er, ,he mapping could also take into ^ s ^ specitying tn e 

Currently there is also one brt .n the P ^ 

je sired reliability leve,. If this bi, is *^ ton and could be 
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service). The use of that bit may, however, be too vague because the GPRS 
defines many other reliability levels as well and this cannot be expressed 
using only one bit. 

The mapping described above in Example 2 may be applied in a 
rather similar way in IPv6. The name of the appropriate field is then Traffic 
Class instead of ToS. 

Fig. 4 illustrates the operation of a GPRS mobile station and GPRS 
network elements, as well as integration with external network QoS concepts 
when the inventive multiple QoS concept and profile tag are employed The 
MS, or more precisely, the software in the terminal equipment TE (eg in a 
laptop computer), and the GGSN, provide mapping of external network QoS 
requirements to GPRS QoS mechanisms, and vice versa, as described in the 
above examples. The TE could for example provide QoS functions through an 
Application Programming Interface (API). The application-level software may 
insert into the data packets, e.g. inside the IP header itself, the QoS 
information or a profile tag, or it can indicate the correct flow which the packet 
belongs to using some other suitable means. It can also use the RSVP to 
convey the necessary information via appropriate mapping layers to lower 
layers. If it performs none of these operations, the GPRS-specific software 
should provide the data packets with a profile tag indicating priority and traffic 
type information, based on available information. The software may for 
example, decide the QoS profile based on the used source and destination IP 
addresses, or on the source and destination port numbers: 

For Mobile Originated (MO) data, the MS schedules data packets 
based on the QoS information (e.g. a profile tag) received from the application 
or from the GPRS protocol suite in the Terminal Equipment. The MS 
schedules the incoming MO packets according to their delay class. In the 
SNDC layer, the MS selects the appropriate LLC SAP (Service Access Point) 
as indicated by the SGSN during PDP context activation or modification. 

Fig. 5 shows a context activation procedure. In step 5-1, the MS 
sends an Activate PDP Context Request (comprising an NSAPI, a PDP type, a 
PDP address, an Access Point Name, the requested QoS Profiles and an 
associated Profile Tag PrT, an Interworking parameter and its associated PrT, 
and PDP configuration options) to the SGSN. Security functions may be 
performed in step 5-2, but they are not relevant for understanding the 
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■ , 5 3 the SGSN validates the request 5-1 . The SGSN creates 
invents. In step fW. the SGSN ^ ^ ^ 

a Tunnel Identifier TID for the requested ^ the 
the requested QoS attributes given ,ts capab ly the cu re ^ 
subscribed QoS P rof,e. Next ,n , £, he SGSN s ^ 
Context Request (cornpns.ng ^^.^^ PrT , an mterworking 
Name, the negot,ated QoS iP«M. and a configuration options) t0 

parameter and its assoc.ated ^ m 8 QoS attributes given its 

the GGSN. The GGSN may also returns a Creat e PDF 

^^^^^T^^P Address, the negotiated QoS 
3 Context Response (compn ^ TID p } t0 the SG SN. 

Profiles with profile tags PrT, *™rvr » ^ 

The SGSN ^^^r.^^Tu- - each 

Next, in step 5-5, the SGSN selects Accept 
negotiated OoS P^l. -a ; Activate^ ^ ^ ^ 
is (comprising a PDP type, a * _ gp SAp , 
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Fig 6 shows a context modffication procedure. In step 6-1, the 

SGSN send!' an Update POP ITZ^^ 
negated QoS Profiles , a nd = ^ „ ^ t0 add , modify or 
and its associated PrT) to the ^oi rece ives from the SGSN a 

canoe, a QoS pro«e of a PDP context^ e G°~e ^ 
negotiated QoS which is ,ncompat,ble With the pur _ 
( eg. the reliability class is insufficient to support th ^W* 
( rei ecs the request. Compatible QoS P^es - »^«rib U .es given its 
operator. The GGSN may aga,n estr, , he negotiated QoS 
capabilities, and the current load. The GGS ^ 
values and, in step 6-2, returns an Update P ^ 
(comprising the TID, the negotiated QoS 6 _ 3 
Intending parameter and s assoc^ an NSAP1 , the 

the SGSN sends a Modify PDP Contort : k q Level 
negotiated QoS Profiles with associated profile tags PrT, 
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and an SAPI for each QoS profile, Interworking parameter and its associated 
PrT) to the MS. In step 6-4, the MS acknowledges by returning a Modify PDP 
Context Accept message. If the MS does not accept the negotiated QoS 
Profiles, it can de-activate the corresponding PDP context(s) using a PDP 
Context Deactivation procedure. 

The choice whether to use retransmission or checksums at the 
LLC/RLC level depends on the reliability class of the corresponding profile. 
The reliability class defines either acknowledged or unacknowledged service 
of LLC, RLC and GTP. Scheduling in the lower layers is performed in 
accordance with the delay class of the corresponding profile. 

The MS may also perform policing of the negotiated PDP context 
attributes of the QoS profile. It may drop non-conforming packets (or change 
the service precedence (i.e. the priority) of those packets to the worst possible, 
i.e. to indicate best-effort). Not only the MS, but also an SGSN may optionally 
perform traffic policing according to the negotiated QoS profile or PDP context 
level attributes. Network nodes may police the throughput levels and the used 
delay classes, reliability classes and service precedence values. Values 
negotiated for the PDP context may be interpreted as maximum allowed 
values or default values for the profiles. PDP context or profile-dependent QoS 
attributes form the basis for charging. For example, there could be a different 
counter associated with each profile used to charge the user. 

The LLC establishes a connection over a SAPI when a new QoS 
profile is activated, requiring a new SAPI. This may happen at PDP context 
activation or modification (e.g. a creation of a new QoS profile). When all (QoS 
profile) flows using the SAPI are released, the LLC connection over this SAPI 
will also be released. Different QoS profiles can be employed between the MS 
and the SGSN. For example, the same SAPI could be used if the mean 
throughput is different but not if the delay class is different. Then the 
LLC/SNDCP layer has to multiplex several NSAPIs of one user onto several 
SAPIs in the MS and SGSN. The LLC/SNDCP layer in an SGSN decides, 
based on the QoS profile, which SAPI it will use to transfer the packets in a 
certain flow. The SNDC layer adds the corresponding profile tag to the data 
packets. It can perform segmentation of SN-PDUs as usual. Then the SNDC 
layer gives the packet to the LLC layer using the appropriate SAPI. The LLC 
layer transmits the packet over the LLC/radio connection as usual. At the other 
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and the SNDC layer receives packets from the different LLEs and associates 
"em 1 «ne correct NSAPIs and further to the corresponding 

P ' aC6, The SGSN reads the QoS information, i.e. the service P""*"* 

«h » 9 k hit rates and the reliability class, of the 

atcated for queuing the concerned packet dass should be. Thrs ,s because 
fZ 1Z are delay-sensKive. and thus cannot cope with long queu.ng 
X^er delay daises are "^^J^LT C 

each data packet is se h informat|0n , n 

in the profile, or based on defauU val es , 1 1 ^^on-oriented 
,he corresponding P^^/ ~ Motionless path for other 
» P* is chosen for n*** das* J ^ ^ ^ 

^ Ihtrbe^dt tht ,0th, or the 2 C,h octet of the header 
(ourr en„y reserve, .for f.ureus^ ^ ^ ^ ^ Q-j-p d h 

too. The GGSN, or an exien.d sg 
external data network QoS definitions and the GPRS QoS, 
This applies both to uplink and downlink data delivery. 
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The same procedure applies to Mobile Terminated (MT) data 
packets only the direction of transmission is reversed. In this case, the GGSN 
selects the appropriate QoS profile and GTP path. The SGSN looks inside the 
downlink GTP header in order to find the profile tag and it deduces the QoS 
information from its local profile record. The SGSN also adds the profile tag to 
downlink SNDCP packets, makes the scheduling based on the delay class of 
the flow/profile, and uses the correct LLC SAPI associated with the profile. The 
Mobile Terminal may change the application's IP header in order to inform the 
Terminal Equipment (TE) of the QoS of the downlink data packet. 
Alternatively, the MS might use some GPRS or PPP specific mechanisms for 
delivering the same information to the TE. Scheduling and policing operations 
inside the network elements are basically the same in both directions. 

As noted above, for uplink data, the GGSN, or an external host, 
modifies the GPRS QoS information to the QoS concepts available in the 
external packet data network. Similarly, for downlink data, the GGSN, or an 
external host, should translate the external network QoS into the GPRS QoS 
definitions in each data packet. The GGSN, or an external host, may optionally 
maintain information about different application connections and traffic flows, 
but this is not required. The flow information can be obtained for example via 
RSVP signalling in the network. The GGSN, or an external host, may 
response to external RSVP messages itself, or it may also pass the RSVP 
messages to the MS which may take part in the RSVP signalling. The capacity 
indicated in RSVP response messages should be in line with the capacity 
reserved for the corresponding QoS profile in the GPRS network. 

As described in the examples above, the Differentiated Services in 
the Internet, like the SIMA approach, can be mapped quite easily to these new 
GPRS QoS concepts. For Differentiated Services, a separate QoS profile 
could be established for each traffic type (i.e. attribute combinations, per-hop 
behaviours) requiring a particular service from the network. The Integrated 
Services are usually associated with traffic flows, which can be mapped to 
different QoS profiles within the GPRS. The Guaranteed Service can thus be 
defined as with the RSVP: the GGSN, or an external host, and the MS on the 
other side, may provide the mapping between QoS profiles and external traffic 
flows, as well as the mapping of QoS parameters. During the RSVP 
negotiation, the GPRS system may indicate that it cannot support various 
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token bucket sizes or maximum packet sizes. Thus, it may require that those 
° rame et re set to conform «c the supported vaiues before it wili accept the 
Reservations. The MS, the SGSN, the GGSN or ah externa, host may 
Z k ow the free capacity in the network and make a decision on the 

Z£££»W»Oc may be mapped to reai-time traffic Cass and 
th^ other ATM traffic ciasses to noh-rea,-time traffic. Prion* may ^be dec. W 
based on both the used traffic class (non-real-t,me Vanable B,t R£ 
AUemaZ Bit Rate, or Unspecified Bit Rate) and other connection-related 

narameters such as mean and maximum bit rates. ,,■,,„ 
parameter^ ^ ^ ^ ^ ^ transmlss , on etwori( ,n 

,k= r-PRS backbone The GPRS QoS concepts may be mapped to the Type- 
5 the GPRS backbone in Prio rity/Traffic Class field in the 

Of-Service parameter in the IPv4^ or t ^ ^ ^ 

,PV6. and vice versa. The flows njhe 1^6 connections, or POP 

ZZ Tth': SltmS -employs ,ese methods, the 
,„ GGSN^ or an external host, could perform mapping o, concepts similarly 
" ^ * - mobiie communications 

network, suTntially - ^-^T^ -yt 

Digital Packet Data (CDPD). embo diments of the 

The description only illustrates preiencu 

*■ •« „«t however limited to these examples, but it may 
30 invention. The invention is not, however, nmiiea 

vary within the scope of the appended claims. 
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Claims 

1. A method for transmitting data packets (DP) in multiple data flows 
to/from a mobile station (MS) in a mobile communications system (HPLMN, 
VPLMN) having a packet data transmission capability, the method comprising 
the steps of: 

setting up a data transmission path for the mobile station (MS) for 
routing data packets (DP) through the mobile communications system 
(HPLMN, VPLMN); 

transmitting data packets (DP) through the mobile communications 
system (HPLMN) between said mobile station (MS) and an external 
communication system (1 1 , 12, VPLMN, HPLMN); 

associating at least one profile (Pr) with said data transmission 
path, said at least one profile comprising at least one quality of service 
parameter, or QoS parameter; 

scheduling and policing the transmission of the data packets (DP) 
within at least one QoS parameter indicated by said profile (Pr); 

characterized by the further steps of: 

associating multiple profiles (Pr) with the transmission path, each 
profile (Pr) comprising at least one QoS parameter; 

providing each of said multiple flows with a profile tag (PrT) 
indicating one of the multiple profiles (Pr) associated with the transmission 
path in question; and 

scheduling and policing the transmission of individual data packets 
(DP) on the basis of said at least one QoS parameter of the profile (Pr) 
indicated by the profile tag (PrT) associated with the data flow in question. 

2. A method according to claim 1, characterized by the steps 

of 

executing at least two applications in said mobile station (MS), each 
application belonging to a class/type and having at least one flow associated 
thereto; 

transmitting, within a single transmission path, data packets (DP) of 
said at least two applications; and 

providing each flow of each application class/type with a profile tag 
(PrT) indicating the QoS parameter required by the respective application 
class/type. 
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3. A method according to claim 2, c h a r a c t e r i z e d by providing 
each flow of each individual application with a profile tag (PrT). 

4. A method according to any one of the preceding claims, 
characterized by providing substantially each individual data packet 

5 (DP) with a profile tag (PrT). 

5. A method according to any one of the preceding claims, 
characterized by providing, as QoS parameters, each profile (Pr) with 
priority information indicating one of at least two priority levels. 

6. A method according to any one of the preceding claims, 
10 characterized by the steps of 

providing in the mobile communications system at least one 
connection leg with at least two paths having different reliabilities; 

providing, as one QoS parameter, each profile (Pr) with reliability 
information indicating one of at least two reliability classes; and 
15 multiplexing the data packets (DP) to said at least two paths 

according to said reliability information. 

7. A method according to any one of the preceding claims, 
characterized by the steps of 

forming in the mobile communications system at least one 
20 connection leg with a connection-oriented path and a connectionless path, the 
former being more reliable than the latter; 

deciding whether to send a data packet (DP) over the connection- 
oriented path or the connectionless path on the basis of said reliability 
information. 

25 8. A method to according claim 7, characterized by 

multiplexing data packets (DP) associated with two or more profiles (Pr) to 
said connection-oriented and connectionless paths in said at least one 
connection leg. 

9. A method according to any one of the preceding claims, 
30 characterized in that at least one of the profiles (Pr) comprises at least 
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one further QoS parameter indicating a further limit for said scheduling and 
policing. 

1 0. A method according to claim 9, characterized in that said 
at least one further QoS parameter includes one or more of the following: 

5 mean bit rate, peak bit rate, service precedence, delay class and reliability. 

11. A method according to any one of the preceding claims, 
characterized in that 

said at least one further QoS parameter defines a mean bit rate; 

the actual mean bit rate used by the mobile station (MS) is 
10 monitored; and 

data packets (DP) to/from the mobile station (MS) are discarded, or 
at least their precedence is lowered if the actual mean bit rate exceeds the 
mean bit rate defined by said at least one further QoS parameter. 

12. A method according to any one of the preceding claims, 
15 characterized by mapping QoS parameters used in the mobile 

communications system (HPLMN, VPLMN) to those used in a user application 
in said mobile station (MS) or to those used in said external communication 
system (11, 12, VPLMN), and vice versa. 

13. A method according to any one of claims 2 to 12, 
20 characterized by: 

establishing one default profile (Pr 0 ) which is associated with said 
transmission path, and a specific profile (Pr) for each application or application 
class/type being executed in the mobile station; and 

reading a QoS parameter from the default profile (Pr 0 ) if the 
25 corresponding QoS parameter is missing from the specific profile in question. 

14. A method according to any one of the preceding claims, 
characterized by associating a packet data protocol context known per 
se with the transmission path. 

1 5. A method according to claim 13, characterized by 
30 associating said multiple profiles (Pr) with said packet data protocol context. 
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16 An apparatus (MS, GGSN) for transmitting data packets (DP) in 
multiple data flows in a mobile communications system (HPLMN, VPLMN) 
having a packet data transmission capability, the apparatus being arranged to: 

set up a data transmission path for the mobi.e stat.on (MS) for 
routing data packets (DP) through the mobile communications system 

(HPLMN, VPLMN); . .. 

transmit data packets (DP) through the mobile communions 
system (HPLMN) between said mobile station (MS) and an externa, 
communication system (11,12, VPLMN, HPLMN); 

associate at least one profile (Pr) with said data transm.ss.on path, 
said at least one profile comprising at least one quality of service parameter, 

or QoS parameter; 

schedule and police the transmission of the data packets (DP) 

within at least one QoS parameter indicated by said profile (Pr); 

c h a r a c t e r i z e d in that the apparatus is arranged to: 
associate multiple profiles (Pr) with the transmission path, each 
profile (Pr) comprising at least one QoS parameter; 

provide each of said multiple flows with a profile tag (PrT) -ndicatmg 
one of the multiple profiles (Pr) associated with the transmission path ,n 

20 qUeSti ° n; Schedule and police the transmission of individual data packets 
(DP) on the basis of said at least one QoS parameter of the profile .(Pr) 
indicated by the profile tag (PrT) associated with the data flow in quest.on. 

17. An apparatus according to claim 16, characterized in 
25 that the apparatus is or comprises a mobile radio station (MS). 

18 An apparatus according to claim 16, c h a r a ct e r i z e d in 
that the apparatus is a support node (SGSN, GGSN) of a packet radio network 
(HPLMN, VPLMN). 
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